home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000034_owner-urn-ietf _Tue Nov 5 07:40:51 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA17578 for urn-ietf-out; Tue, 5 Nov 1996 07:40:51 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA17573 for <urn-ietf@services.bunyip.com>; Tue, 5 Nov 1996 07:40:45 -0500
  3. Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA00898  (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 07:40:39 -0500
  5. Received: by seawall with  (8.6.12/) id HAA15012; Tue, 5 Nov 1996 07:40:38 -0500
  6. Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3)
  7.     id sma015008; Tue Nov  5 07:40:13 1996
  8. Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail
  9.     id <327F35D5@MSMAIL.INDY.TCE.COM>; Tue, 05 Nov 96 07:40:53 EST
  10. From: Fisher Mark <FisherM@is3.indy.tce.com>
  11. To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>,
  12.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  13. Subject: RE: [URN] Resolution Services (N2L etc)
  14. Date: Tue, 05 Nov 96 07:41:00 EST
  15. Message-Id: <327F35D5@MSMAIL.INDY.TCE.COM>
  16. Encoding: 30 TEXT
  17. X-Mailer: Microsoft Mail V3.0
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Fisher Mark <FisherM@is3.indy.tce.com>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. >1.2 It strikes me that specifying available service requests (N2L, N2R etc)
  24. >should not be the job of DNS or any URN resolution mechanism. You are
  25. >adding
  26. >metadata about the address that the name resolves to (i.e. allowed
  27. >methods).
  28. >NAPTR should simply get you to the place you asked for by mapping names to
  29. >addresses.
  30. [...]
  31. >OK, it may be *easier* to hack it this way, but that's not the point. You
  32. >are embedding a duplication of meta-information in DNS which will always be
  33. >prone to being out of date, unreliable, etc. Especially if the world moves
  34. >to be much more dynamic in this area in the decades you envisage this
  35. >lasting. More importantly, this information potentially has a different TTL
  36. >than the address itself, so it will break your caching.
  37.  
  38. But this is meta-information that is not easy to change.  It is not like, 
  39. "oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll 
  40. support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only 
  41. support whois++", etc.  Rapidly changing what final resolution services are 
  42. supported is not a particularly easy task, or a desirable task even when it 
  43. is made easy.
  44.  
  45. Could one (or more) of the DNS wizards on the list speak as to what the 
  46. average TTL tends to be?  From what Bob is saying, it sounds like he expects 
  47. the TTL of the NAPTR record to be a longer time than the expected time 
  48. between final resolution service changes.
  49. ======================================================================
  50. Mark Leighton Fisher                   Thomson Consumer Electronics
  51. fisherm@indy.tce.com                   Indianapolis, IN